INDEX | PREV | NEXT
LBMAKE
SECOND GENERATION LINK LIBRARY MANAGER
The LBMake utility is similar to LibMake but greatly enhances your
ability to manage the compiling of link libraries from source code. The
LBMake utility uses a control file called "lib.def" in the directory
you run lbmake from. For a good example of a fully working LBMake
system refer to the LIB.DEF file in the DCC:LIB/ directory (containing
the full compilable library source to DICE).
LBMake understands the basics of compiling source files into objects
and JOINing objects into libraries as well as how to turn .FD files
into tag libraries. LBMake is used to generate all of DICE's
link libraries and object modules.
The LBMake control file, "lib.def" determines LBMake's operation in
conjuction with keywords you give it. The control file may contain
lines of the following form:
@Type <symbol> <options>
The @Type command associates a set of compiler options with a
symbol. For example:
@Type s -ms -r -pr
You normally have several @Type commands denoting various memory
models you wish to generate libraries for. When you run LBMake,
any keywords you specify on the command line which match symbols
specified in @Type commands will cause the associated options to
be used when compiling source files. By specifying several keywords
on the LBMake command line you can merge options for several
memory model combinations.
The @Type symbols are merged together to create a single symbol
which can be used to modify the name of the generated library
or object module.
@Objects <symbol> <filepath>
The @Objects command defines a symbolic name which will later be
used to reference individual files that are to be compiled into
individual object modules. The <filepath> contains the filename
template that is to be used to name the object files after
compilation, where %s denotes the name of the object module.
For example:
@Objects startup dlib:%s
If, later on, the 'startup' symbol is associated with the files
fubar/a.c, fubar/b.c, and fubar/c.c LBMake will, when asked to
compile 'startup', generate the object modules dlib:a.o, dlib:b.o,
and dlib:c.o from their source files.
You may specify multiple @Objects commands but should specify at
most one @Objects reference at a time on the LBMake command line,
as in the example above.
@Library <symbol> <filepath>
The @Library commands is similar to the @Objects command but
indicates that all files referenced by <symbol> are to be
JOIN'd together into a single result. For example:
@Library clib dlib:c%s.lib
The filename template in this case reflects any @Type commands
which you have activated via the LBMake command line. For
example, if you ran the following LBMake:
1> LBMake s r clib
LBMake would commence to compile objects associated with the 'clib'
symbol, JOIN them together, and name the result 'dlib:csr.lib'.
You may specify multiple @Library commands but should specify at
most one @Library reference at a time on the LBMake command line,
as in the example above.
@DefTree <filepath>
The @DefTree command defines the default DIRECTORY where
intermediate files are to be stored. The name of the directory
can depend on the @Type commands which have been activated
thereby giving you separate directories for separate memory
models.
@DefTree dtmp:comp3/lib_%s/
So, for example, if you were to 'LBMake s r clib' LBMake would put
the associated object modules in 'dtmp:comp3/lib_sr/'.
@AltTree <symbol> <filepath>
The @AltTree command works like @DefTree but allows you to specify
a symbol on the LBMake command line which overides the @DefTree.
@AltTree pass2 dtmp:comp2/lib_%s/
You may specify multiple @AltTree commands but should specify at
most one on the LBMake command line. This feature is most useful
in a production system to generate 'experimental' versions of a
library until one is ready for the next release, then generate a
'master' version.
SPECIFYING FILES
The remainder of the "lib.def" control file contains file
specifications.. i.e. a list of files and which libraries they
apply to. A file can apply to more then one library. The general
format for the file list is:
<filename> +/-<symbol> +/-<symbol> +/-<symbol> ...
Each file is followed by one or more symbols. For example:
amiga/profile.c +clib +uclib +free -pass2
Would indicate that the amiga/profile.c module is associated with the
library defined by the symbol 'clib', the library defined by the symbol
'uclib', and the library defined by the symbol 'free' (i.e. these three
symbols are part of @Library commands). However, the file does not
exist in any of these libraries of the 'pass2' symbol is specified on
the Command line, where 'pass2' also refers to an @AltTree command.
The basic idea is that you list every file for every library in a
particular project, just as I have done in my "lib.def" file for DICE,
then use LBMake to generate the actual .lib and .o files.
LBMake will create a duplicate directory structure in the object tree
as specified by @DefTree (or an active @AltTree). It appends the
FULL PATH of the source file to the destination tree so, for example,
if you were to:
1> LBMake s r clib
The LBMake would compile 'amiga/profile.c' into
'dtmp:comp3/lib_sr/amiga/profile.o'
Therefore, you may not specify any absolute file paths in order for
LBMake to work properly.
.FD FILES
LBMake supports the generation of tag libraries from .FD files. It
recognizes a .FD file by the .FD extension in the file specification.
In order to properly support .FD files LBMake requires that the
file specification be of the following form:
[directory_path]filename_lib.fd +/-<symbol> +/-<symbol> ...
Why the brackets? Well, remember what I said about not being able to
use absolute filepaths because they screw up the placement of object
modules in the object tree? Brackets provide a solution to this
problem when you have no choice but to use absolute file paths. The
part of the path in brackets will be IGNORED when it comes to figuring
out what the object file name should be. This is especially important
for .FD files which are generally put elsewhere.
To further automate operation LBMake looks for the prototype file
associated with the .FD file using the same path but munging the
'_lib.fd' part to '_protos.h' and munging '/fd/' or ':fd/' into
'/clib/' or ':clib/'. In otherwords, it munges something like:
[dinclude:amiga20/fd/]mathieeesingbas_lib.fd into
[dinclude:amiga20/clib/]mathieeesingbas_protos.h
AUTOINIT CODE INCLUSION
For autoinit code inclusion one needs to specify the actual
name of the library, e.g. 'fubar.library', along with each .FD file
name using the following format:
[directory_path]filename_lib.fd,libraryname +/-<symbol> +/-<symbol> ...
For example:
h/fd/myfubar_lib.fd,fubar.library +mylib
Converted using GuideML V1.6, a converter written by Richard Körber <shred@chessy.aworld.de>